阳振坤：分布式技术引领关系数据库发展
半个世纪以来，全球诞生了一些伟大的关系数据库：1970 年代出现的 Oracle，1980 年代出现的 DB2、SQL Server，这是三个目前最流行、最优秀的商业数据库；1990 年代诞生了目前最流行的两个开源的数据库 PostgreSQL 和 MySQL。从此以后，全球再也没有诞生新的主流关系数据库。
关系数据库之所以成为今天信息社会的基础设施，是因为它提供的记账、转账和算账等的功能以及这些功能的事务属性，即事务的 ACID：原子性、一致性、隔离性和持久性。这些能力为商业、政务、互联网等等提供了很大的便利。
与此同时，信息社会基础设施的角色，也对关系数据库的系统稳定性、数据正确性、服务可靠性等提出了很高的要求，再加上关系数据库本身的复杂性和技术挑战，因此研制一个可在生产中使用的关系数据库门槛非常高、难度非常大。
今天最主流的关系数据库都是集中式的，尽管支撑了当今整个信息社会，但集中式数据库面临了很大的挑战。
第一， 难以扩展。集中式本质上其实是个单机系统，它依赖单一的共享存储。
第二，成本高昂。因为整个系统的可靠性、稳定性以及性能都建立在单个硬件的可靠性、稳定性和性能的基础上，这使得成本居高不下。
互联网时代的到来让这个问题变得更加严重，在互联网时代之前，比方说商场或银行或酒店柜台，不管有多少顾客，这些柜台的数量是稳定、确定的，此时整个系统只要按照最大的操作员数量来进行设计、测试，系统就能很好的工作，不管有多少人排队，系统的最大流量都不会超过设计流量。
到了互联网时代，每个人、每部手机都成了一个操作员，整个业务的流量，增长了 100 倍、1000 倍甚至是更多，并且业务流量在短时间内还可能迅速增加或降低，此时如果还按照最大的流量来搭建系统，可能要搭建一个几亿个操作员的流量的系统，甚至更大。
不止如此，访问量、并发量的激增还带来了数据量的巨大增长，企业需要对这些数据进行分析处理（即算账），但这个数据量已经远远超出了单个集中式数据库的存储容量。对于交易处理，人们还可以对业务做拆分，把业务拆小，让每个拆小后的业务可以运行在一个单机数据库上，就像人员和轻型装备可以分开用多架小飞机进行空运一样。但是，当人们要对这些海量数据进行分析处理的时候，就必须有一个容量足够大的数据库，就像一些重型装备，比如坦克、大炮等，无法拆小后用小飞机空运，而必须有大飞机才行。对于数据库，这种大飞机就是分布式数据库。
过去的几十年来，学术界讲 “One Size doesn't Fit all ”，一个尺寸不能适合所有人。但是，从企业家的角度来看是另外一回事，因为企业期望一个系统可以解决其业务问题，这样能让企业把更多精力放到业务上。
也许有人说，并不是什么场合都需要像“大飞机”这样的大数据库，分布式数据库只有大企业或者至少大中型企业才需要。事实上，大、中型企业肯定用得到分布式数据库，但是小微企业依然能够从分布式数据库中间受益。
以上图这个企业的业务曲线为例，很多时间业务量都在一个比较低的水位上，只有某些时段在一个较高的水位上，这也是几乎所有企业的业务特征。
今天的服务器的计算和存储能力越来越强悍，根据这个企业的最高业务流量来配置一台高性能的数据库服务器，确实就可以支撑这个企业的业务，但是这有很大的浪费。因为在大多数时候，服务器的处理能力没有得到充分发挥。采用分布式数据库，可以有另外一个思路，平时它的数据库是一台配置比较低的虚拟机服务器，如果业务流量增加了，利用分布式的能力随时增加虚拟服务器，业务流量更大时，虚拟服务器数量还可以再进一步增加，当业务高峰过了以后，这些虚拟服务器就可以逐步减掉，这样大幅度降低了企业成本。
关系数据库的研制十分困难，分布式关系数据库的研制更加困难，分布式关系数据库是否可行？这儿我们一起看两个现实中的例子。一个是 Google 的 Spanner，可能很多人了解它是从分布式存储直接跨到分布式数据库的；另一个是中国的 OceanBase 数据库，是从半分布式数据库到高可用数据库再到分布式关系数据库，虽然两者的技术路径不一样，但是结果是殊途同归。
我的汇报就到这里，谢谢大家。
往期推荐
▼ 点击文末“阅读原文”，了解更多